Dynamic service time // group activities together #508
Conversation
The new policy will group activities together, so that their start and end times are matching if it would be possible at all. When comparing two activities to determine the service time, the greater one will be selected.
|
@oblonski could you check out this early draft of a PR to exchange some ideas and feedback on this? |
jsprit-examples/src/main/java/com/graphhopper/jsprit/examples/DynamicServiceTimeExample.java
Outdated
Show resolved
Hide resolved
jsprit-core/src/main/java/com/graphhopper/jsprit/core/util/ActivityTimeTracker.java
Outdated
Show resolved
Hide resolved
This reverts commit 0e45870.
This reverts commit 452a8c3.
After all activities have been inserted in a route and the ActivityTimeTracker has updated the times of the activites, check if some of them could be group together. A activity belongs to a group of activities if their locations are the same and if they could be served at the same time. This is achieved by iterating over the activites for a route when `UpdateActivityTimes.finish` is called.
When coordinates are not provided for a location, fall back to the object comparison for locations `loc.equals(other)` to evaluate if two activities happen at the same location.
|
Hej @oblonski! Happy to report that I overhauled the implementation of using a dynamic service time for the activities. I've added one integration example as well as some test cases for the I don't know if this behaviour should be enabled by default though or if it should be controlled by a toggle. Happy to get some feedback on this. |
|
Interesting observation when running the PR above. It seems as though the code is run after a route has been generated, to return the route to be newly timed route (through the .finish() code). Practically, what this means, is a route which uses a vehicle type which available for 12 hours, will take a 12 hour route with sites loaded adjacently (i.e 3 x 30 minute loading at the same site), and will generate a newly timed route being 12hours - 60 minutes, so will at most ever be 11 hours utilised. In theory, the newly timed stops may be violating time windows as well (TBC). Will revert if I have more information, or a solid approach to using the above code. |
|
Yeah there are some more missing things for this to work properly, especially for each Insertion class. I didn't find the time yet to further improve the PR. |
|
All good, was running into the same problem as yours and was wondering if I could use your PR! I ended up taking a different approach which is proving promising, but not without challenges! You can see those changes here |
Description
This is a naive proof of concept to group activities at the same location with different service times together.
It has been requested / discussed several times in the forums: 1, 2, 3.
Let's consider this route:
Before this change, we would get something like:
Afterwards, it will change to:
This is a rather naive approach by adjusting the times computed in the class UpdateActivityTimes.
The implementation of this was done after all activities have been inserted into a route, when calling the
finish()method of this state updater.If two or more activities at are happening at the same place and time, then they could be grouped together, having identical
arrivalandendtimes and adjusting the following activities accordingly by the time that has been saved.